EC2 Windows ServerでのRemote Desktop Service構成パターン
しばたです。
最近EC2のWindows ServerでRemote Desktop Serviceを使った構成に関する相談を何件か受けており、せっかくなのでブログでも知見を共有しようと思います。
免責事項
本記事ではMicrosoftライセンスに関わる内容があるため以下の点を免責事項とさせてください。
本記事で触れるライセンスは全てWindows Serverに関わるものでありその正式な判断はすべてMicrosoftの責任下にあります。
以後説明する内容でライセンス上の疑問が出てそれをAWSに問い合わせても「Microsoftに聞いてくれ。」以外の回答は得られないはずです。
このため、本記事に関するライセンス上の嫌疑は全てMicrosoftに問い合わせる様にしてください。
Windows ServerにおけるRemote Desktop Serviceの基本
現在サポートされているWindows Serverは、デフォルトの状態では「管理用途[1]に限り2セッションまでRemote Desktopを同時使用できる」様になっています。
このため、管理用途外の利用および3人以上のユーザーでWindows ServerへRemote Desktop接続してデスクトップ環境を利用したい場合は追加でRemote Desktop Service CAL(RDS CAL)もしくはRemote Desktop Service SAL(RDS SAL)を購入し、Windows Serverに所定の設定を施す必要があります。
RDS CAL/RDS SALについて
RDS CALは管理用途外でRemote Desktop Serivceを利用する際に必要となるCALです。
RDS CALには利用デバイスに割り当てるDevice RDS CALと利用ユーザーに割り当てるUser RDS CALがあります。RDS CALはWindows Serverのバージョン毎で分かれバージョン間での互換性もあるのですが本記事ではその点は割愛します。
RDS CALは端的に言ってしまうとオンプレ環境専用のライセンスでありAWSをはじめとしたクラウド環境(＝SPLA契約下)では使用できません。
クラウド環境ではCALに変わるライセンスとしてSAL(Subscriber Access License)が提供されておりRDS CALの代わりにRDS SALが必要となります。
SALはほとんどの場合でユーザーライセンスであり、RDS SALはユーザーに割り当てるUser RDS SALのみ提供されています。
このため、通常、AWS環境で管理用途外のRemote Desktop Serviceを使いたい場合はRDS SALを購入する必要があります。
ここまでをまとめると下表の様になります。
| 利用可能環境 | 適用対象 | ライセンス種別 | 特記事項 |
|---|---|---|---|
| オンプレ環境 | ユーザー | User RDS CAL | |
| オンプレ環境 | デバイス | Device RDS CAL | |
| クラウド環境(SPLA) | ユーザー | RDS SAL | RDS SALはユーザーライセンスのみ |
補足 : ライセンスモビリティについて
Microsoftではオンプレ環境向けライセンスをAWSをはじめとしたクラウド環境に移動できるライセンスモビリティという制度を提供しています。
ライセンスモビリティはMicrosoftが認めたベンダーに対して移動可能であり、全てのソフトウェアではなく特定ソフトウェアのみ移動可能となります。
ライセンスの移動先としてAWSは認定されておりRDS CALは移動可能な対象の一つです。このためRDS SALを買う以外にもライセンスモビリティによりRDS CALを移動するパターンもRemote Desktop Serviceを利用可能なパターンとしてあり得ますが本記事では触れません。
なお、ライセンスモビリティの行使にはMicrosoftによる審査が必要となりますので詳細はMicrosoftに問い合わせてください。
ライセンスの上の制約
詳細は後述しますが、RDS CAL/RDS SALを購入しRemote Desktop Serviceを利用する場合はサーバーの設定変更とRDS CAL/RDS SALのライセンス登録を行う必要があります。
サーバーの構成に関してActive Directory環境かワークグループ環境かの違いでライセンス上の制約があるため先に触れておきます。
以下のドキュメントはワークグループ環境でRemote Desktop Serviceを構成する手順に関するものなのですが、
この中で
重要
ワークグループサーバーでRDSを構成すると、以下の追加の制限が作成されます。
- ユーザーごとのライセンスではなく、デバイスごとのライセンスを使用する必要があります。 詳細については、「使用 許諾契約書」(CAL)を参照してください。
と記載されており、ワークグループ環境ではDevice RDS CALしか使用できない制約があります。
RDS SALはユーザーライセンスのみの提供ですのでAWS環境でRemote Desktop Serviceを使いたい場合はActive Directory環境であることが事実上必須となりますのでご注意ください。
(ライセンスモビリティによりDevice RDS CALを移動すればワークグループ環境での利用もライセンス上問題ないと思われますが、言質はとっておらず、その是非は未確認です。)
Remote Desktop Serviceの構成パターン
前置きが長くなりましたが、ここからRemote Desktop Serviceの構成パターンについて触れていきます。
Remote Desktop Serviceはその前身であるTerminal Serviceを含めるとだいたい20年くらいの非常に長い歴史があるサービスです。
Remote Desktop Serviceはその歴史のなかで単純にサーバーにリモート接続するだけでなく、AppStream 2.0の様なアプリケーションストリーミングを行うMicrosoft RemoteAppやWorkSpacesの様なVDI機能も有しています。
Remote Desktop Serviceはサービス全体では以下の機能から構成されています。
| 機能名 | 機能 | 備考 |
|---|---|---|
| Remote Desktop License | RDS CAL/RDS SALの管理を行うライセンスサーバー | このサーバーに購入したRDS CAL/RDS SALを登録する |
| Remote Desktop Session Host | Remote Desktop環境の提供、および、RetemoAppのアプリケーションサーバー | |
| Remote Desktop Virtualization Host | VDI用仮想マシンのホストとなるサーバー | |
| Remote Desktop Connection Broker | RDSに関わる各種機能を集中管理するサーバー | |
| Remote Desktop Web Access | RemoteApp/VDIのWEBポータルを提供するサーバー | |
| Remote Desktop Gateway | インターネット越しにRDP接続したい際に使用するゲートウェイおよびリバースプロキシサーバー |
Remote Desktop Serviceを構成する場合、Remote Desktop Connection Broker (以後RD Connection Broker)を中心に全ての機能を使える様にするフルインストールするパターンと、最低限Remote Desktop License (以後RD License)とRemote Desktop Session Host (以後RDSH)の機能のみをインストールする2パターン存在します。
2つのパターンに決まった名称はありませんが本記事ではそれぞれ「フルインストール」「RDSHのみインストール」と呼ぶことにします。
「フルインストール」はActive Directory環境であることが必須であり、「RDSHのみインストール」はワークグループ環境でも可能ですが先述の通りライセンス上の制約があります。
このため構成可能なパターンを表にまとめると以下の様になります。
| インストール方法 | 利用環境 | 構成可否 | 特記事項 |
|---|---|---|---|
| フルインストール | Active Directory環境 | 〇 | Remote Desktop Serviceのすべての機能を利用可 |
| フルインストール | ワークグループ環境 | × | 構成不可 |
| RDSHのみインストール | Active Directory環境 | △ | RemoteApp/VDIといった機能は原則使えない |
| RDSHのみインストール | ワークグループ環境 | △ | RemoteApp/VDIといった機能は原則使えない + ライセンス上の制約がある |
以降はこの中から実現可能な3パターンについて解説していきます。
1. Active Directory環境にフルインストールする場合
最初にAcitve Directory環境にフルインストールする場合の構成例を紹介します。
こちらの図はActive Directory環境に「RD License Server」と「RDSH Server」の2台構成としており、RDSH ServerにはRD Connection BrokerをはじめとしたRemote Desktop Serviceの各種機能をインストールする構成となります。
サーバー台数を限界まで減らしたい場合はRD License Serverも集約しすべての機能を1台に収めることも可能です。
なお、フルインストールの場合はRemoteApp/VDIをそれなりの規模で運用するユースケースもあるため冗長性を考慮する場合はそれぞれの機能ごとで多重化することが推奨されています。
本記事では各機能の多重化の詳細については触れませんが、de:code 2016で発表された以下の登壇資料が詳しいのでぜひ参考にしてみてください。
(P18 ～ P19 参照の事)
上記資料はAzureでの構成例ですが、AWSで構成を組む場合も同様の考慮が必要となります。
2020.10.27追記 構築手順
このパターンでの構築手順を以下の記事にまとめました。
2. Active Directory環境にRDSHのみインストールする場合
次にActive Directory環境にRDSHのみインストールする場合の構成例を紹介します。
おそらくAWS上でRemote Desktop Serviceを使いたいという場合、このパターンになることが一番多いであろうと思われます。
基本的な構成はフルインストールの場合と同様ですが、「RDSH Server」にはRDSH以外の機能はインストールしません。
要件が単純に「多人数でRemote Desktop接続を使いたい」だけであればこれで問題ありません。
こちらもサーバー台数を限界まで減らしたい場合はRD License Serverも集約しすべての機能を1台に収めることが可能です。
2020.10.28追記 構築手順
このパターンでの構築手順を以下の記事にまとめました。
3. ワークグループ環境にRDSHのみインストールする場合
最後にワークグループ環境にRDSHのみインストールする場合の構成例を紹介します。
こちらは技術的には実現可能ですがライセンス上の制約があるためAWS上で採用することは少ないと思われます。
この構成を実運用することはライセンス的に不可
ワークグループ環境ですのでDomain Controllerが無い以外は前項のパターンと同様の構成となります。
Acite Directory環境との違いは「利用可能なライセンスがデバイスライセンスのみである」点になります。
2020.10.28追記 構築手順
このパターンでの構築手順を以下の記事にまとめました。
最後に
以上となります。
まずは各構成パターンとライセンス上の制約について解説しました。
後日各パターンでの環境構築方法を追記する予定ですのでご期待ください。
本記事の内容がAWS上でRemote Desktop Serviceの利用を検討している方の役に立てば幸いです。
なお、何が 管理用途 に該当するか厳密に定義されたドキュメントはありません。気になる方はMicrosoftに問い合わせてください ↩︎
